home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 883 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.6 KB
  1. From: Michael Smith <miff@apanix.apana.org.au>
  2. Subject: Reality check here...
  3. Date: Wed, 19 Jan 1994 13:48:13 -17634834 (DST)
  4. In-Reply-To: <9401171124.AA20195@amethyst.techfak.uni-bielefeld.de> from "itschere@techfak.uni-bielefeld.de" at Jan 17, 94 12:24:26 pm
  5.  
  6. >
  7. >Michael Hohmuth writes:
  8. >
  9. >> I'd like to propose not to go into too much detail in defining a "standard"
  10. >> for the file system layout.  Different distributions will handle things
  11. >> differently, so I don't see much sense in discussing at this time where 
  12. >> particular binaries of particular flavours of Unix should live, especially
  13. >> since most programs are independent of their physical location.
  14. >
  15. > That's as long ok as you can either ensure there's only one program with
  16. >a given name in the search path, or all of them offer the wanted UNiX
  17. >functionality.
  18.  
  19. To be perfectly frank, most people who would be wanting an environment 
  20. like this would know about these issues.
  21.  
  22. > If you've got two versions of `more' for example, one able to handle
  23. >things like 'this.my.file' and another which is not, than it's a question
  24. >of what path comes first if the next tool which needs `more' runs ok or
  25. >breaks.
  26.  
  27. Hmm. Not too many programs use tools of which there are multiple versions, 
  28. and any program which groks my.file.name should be able to handle the 8.3
  29. limited subset with little or no trouble.
  30.  
  31. > Guess you won't want each tools to do this check by its own each time
  32. >it uses other programs, so either you cleary define unique paths, or you
  33. >ensure that really every program shares your view of filenames etc...
  34.  
  35. Or you just push for a universal set of tool standards - they should be
  36. filesystem-limitation aware, etc...
  37.  
  38. > Hmmm... New idea: Perhaps the `global' install programm should check each
  39. >executable in the whole tree for a symbol _unixmode or whatever, just like
  40. >_stksize is used for other purposes to check if all programs are supposed
  41. >to be ok. If the necessary filename conversion routines and other stuff
  42. >goes to the library, this one would be totally transparent to the user,
  43. >just like the _stksize stuff. Get the source, recompile it and you're right
  44. >on. This symbol could contain a version number of the standard the program
  45. >is able to deal with.
  46.  
  47. Hmm.  
  48.  
  49. Oh, and btw, given that the big stress here is dealing with *nix software, 
  50. bear in mind the huge diversity of *nix path layouts...
  51.  
  52. >bye,
  53. >TeSche
  54.  
  55. -- 
  56. # mike smith : miff@apanix.apana.org.au - Silicon grease monkey        #
  57. # "The question 'why are the fundamental laws of nature mathematical'  #
  58. # then invites the trivial response 'because we define as fundamental  #
  59. # those laws which are mathematical'". Paul Davies, _The_Mind_of_God_. #
  60.